-
Notifications
You must be signed in to change notification settings - Fork 25.6k
[Build] Rework internal build plugin plugin to work with Isolated Projects #123461
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
c79bac8 to
ca0117d
Compare
ed1832e to
9759f49
Compare
|
Pinging @elastic/es-delivery (Team:Delivery) |
jozala
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
modules/aggregations/build.gradle
Outdated
| classname ='org.elasticsearch.aggregations.AggregationsPlugin' | ||
| extendedPlugins = ['lang-painless'] | ||
| extendedPluginProjects { | ||
| "lang-painless" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This syntax seems a bit verbose. Is there a way we could use just the project path, and resolve something from the project at runtime to determine the plugin name? Most of the time this is just the project name, so having to specify it twice along with the extra syntax feels like unnecessary boilerplate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that unfortunately the naming is not deterministic across the different plugins. At the moment the actual name is declared in the build script only. We could resolve the name maybe by resolving the generated plugin properties, but for now I prefer this little bit boilerplate in the definition over the constant cost of trying to be clever here and resolve that dynamically.
Looking at this again, I just realize we might have a better way to move forward here as we only need the the project path atm to configure a potential test cluster automatically. Given we use less and less the test cluster plugin we probably tweak this to not generally change the plugin declaration but just do the module dependency in the test clusters explicitly.
puh, let me revisit this again 🤡
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rjernst turns out alls this was basically not required in our current codebase. see https://github.com/elastic/elasticsearch/pull/123461/files#r1995753719
- Update restrited buildservice
484b12a to
dfe7d45
Compare
| if (isModule == false || isXPackModule) { | ||
| addNoticeGeneration(project, extension); | ||
| } | ||
| project.afterEvaluate(p -> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this was only used by internal plugins that
a) still rely on test cluster plugin,
b) extend other plugins
c) do not use default distribution
which is actually ZERO
c3ab3e4 to
ce2aef6
Compare
rjernst
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. FWIW it would be nice to not have to specify dependencies twice, once in the plugin properties block, and again under dependencies. But this is good on its own.
true. we would need some stronger modelling here for this. |
…jects (elastic#123461) This fixes a general flaw in our build logic where we reach out to configurations of other projects. This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration of subprojects.
…jects (elastic#123461) This fixes a general flaw in our build logic where we reach out to configurations of other projects. This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration of subprojects.
…jects (elastic#123461) This fixes a general flaw in our build logic where we reach out to configurations of other projects. This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration of subprojects.
…jects (elastic#123461) This fixes a general flaw in our build logic where we reach out to configurations of other projects. This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration of subprojects.
…jects (elastic#123461) This fixes a general flaw in our build logic where we reach out to configurations of other projects. This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration of subprojects.
* main: (95 commits) Mute org.elasticsearch.datastreams.lifecycle.DataStreamLifecycleServiceIT testLifecycleAppliedToFailureStore elastic#124999 Merge template mappings properly during validation (elastic#124784) [Build] Rework internal build plugin plugin to work with Isolated Projects (elastic#123461) [Build] Require reason for usesDefaultDistribution (elastic#124707) Mute org.elasticsearch.packaging.test.DockerTests test011SecurityEnabledStatus elastic#124990 Mute org.elasticsearch.xpack.ilm.TimeSeriesDataStreamsIT testRolloverAction elastic#124987 Mute org.elasticsearch.packaging.test.BootstrapCheckTests test10Install elastic#124957 Mute org.elasticsearch.integration.DataStreamLifecycleServiceRuntimeSecurityIT testRolloverLifecycleAndForceMergeAuthorized elastic#124978 Mute org.elasticsearch.xpack.esql.action.CrossClusterAsyncQueryStopIT testStopQuery elastic#124977 Mute org.elasticsearch.xpack.esql.action.CrossClusterAsyncQueryStopIT testStopQueryLocal elastic#121672 Mention zero-window state in networking docs (elastic#124967) Remove remoteAddress field from TransportResponse (elastic#120016) Include failures in partial response (elastic#124929) Prevent work starvation bug if using scaling EsThreadPoolExecutor with core pool size = 0 (elastic#124732) Re-enable analysis stemmer test (elastic#124961) Mute org.elasticsearch.xpack.esql.action.CrossClusterAsyncQueryStopIT testStopQueryLocalNoRemotes elastic#124959 ESQL: Catch parsing exception (elastic#124958) ESQL: Improve error message for ( and [ (elastic#124177) Mute org.elasticsearch.xpack.esql.qa.single_node.EsqlSpecIT test {lookup-join.MvJoinKeyFromRow SYNC} elastic#124951 Mute org.elasticsearch.datastreams.lifecycle.DataStreamLifecycleServiceIT testErrorRecordingOnRetention elastic#124950 ... # Conflicts: # server/src/main/java/org/elasticsearch/index/mapper/vectors/DenseVectorFieldMapper.java # server/src/test/java/org/elasticsearch/index/mapper/vectors/DenseVectorFieldTypeTests.java
…jects (elastic#123461) This fixes a general flaw in our build logic where we reach out to configurations of other projects. This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration of subprojects.
This fixes a general flaw in our build logic where we reach out to configurations of other projects.
This is not best practice and breaks future initiatives like IsolatedProjects that allow parallel configuration
of subprojects.